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VELANET  Communication  Protocols  Between  the 
CCP  and  SIP  and  Between  The  CCP  and  DP 

1.  INTRODUCTION 

The  VELANET,  a seismic  data  collection  network  Including 
approximately  six  on-line  array  stations,  is  being  implemented 
by  the  VELA  Seismological  Center  under  DARPA  sponsorship.  The 
objective  of  the  network  is  to  provide  data  for  research  in 
nuclear  test  detection  and  identification.  The  Seismic  Data 
Analysis  Center  (SDAC)  will  perform  event  detection  and  analysis 
to  generate  a network  event  list.  The  data  collected  by  the 
network  will  be  filed  in  a large  digital  storage  facility  at 
Computer  Corporation  of  America  (CCA). 

The  Communication  and  Control  Processor  (CCP)  is  the  central 
node  in  the  VELANET.  It  receives  data  from  the  seismic  stations 
over  leased  line  and  ARPANET  circuits,  reformats  the  data  as 
needed,  and  forwards  selected  data  to  the  Seismic  Input  Processor 
(SIP)  at  CCA  and  to  the  Detection  Processor  (DP)  over  the  ARPANET 

This  document  describes  the  revised  protocols  and  formats 
for  communication  between  the  CCP  and  SIP,  and  between  the  CCP 
and  DP.  The  revised  protocols  are  expected  to  be  Implemented 
in  the  spring  of  1977. 
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2.  OVERVIEW 

The  amount  of  data  that  can  be  forwarded  from  the  CCP  is 
expected  to  be  limited  by  the  ARPANET  capacity.  It  is,  therefore, 
important  to  use  the  ARPANET  efficiently.  Load  on  the  ARPANET 
resources  is  controlled  by  three  parameters:  1)  total  bandwidth, 

2)  number  of  messages,  and  3)  number  of  "packets".  Packets 
contain  1008  bits  of  data  and  messages  contain  up  to  8 packets. 

Optimum  use  of  the  network  is  achieved  with  full  packets 
and  full  messages.  In  order  to  approach  that  goal,  the  protocols 
described  in  this  document  treat  all  communications  except  message 
acknowledgement  as  a continuous  time  sequence  data  stream.  When- 
ever 7,968  bits  of  data  are  available  in  the  stream,  they  are 
formatted  into  a message  with  80  bits  of  message  header  and 
checksum  information,  and  thvj  message  is  transmitted.  In  order 
to  avoid  excessive  delays,  an  alternate  condition  for  transmitting 
a message  is  that  data  waiting  to  be  sent  is  one  second  old. 

All  messages  will  contain  Integer  multiples  of  2 bytes  (16  bits) 
of  data. 

When  the  protocol  rules  for  a particular  path  require  message 
acknowledgement,  the  acknowledge  messages  will  form  a separate 
data  stream.  This  avoids  the  excess  traffic  resulting  from 
acknowledging  acknowledge  messages.  On  low  data  paths,  the 
added  acknowledge  messages  could  be  a majority  of  the  traffic 
without  this  separate  data  stream. 

Within  each  regular  message,  data  is  organized  by  fixed  format 
blocks  with  different  block  formats  for  each  of  6 types  of  data. 
Each  block  will  start  with  a standard  header  giving  the  block 
type  and  length.  A message  in  the  main  data  stream  does  not 
have  to  start  or  end  on  a block  boundary.  The  message  header 
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control  and  flow  control  procedures  and  messages.  The  host 
level  protocol  rules  are  stated  In  Section  6. 
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3.  DATA  BLOCK  FORMATS 

There  are  seven  types  of  data  blocks  used  in  communication 
among  the  CCP,  the  SIP,  and  the  DP.  Six  of  these  will  appear 
as  blocks  in  the  main  data  stream.  Acknowledge  data  appears 
as  separate  messages.  The  six  regular  data  block  types  and  the 
corresponding  type  identifiers  are  listed  in  Table  1.  The 
format  of  the  data  in  each  block  type  is  described  below. 


TABLE  1:  Block  Type  Identifiers 


0 

4 

5 
8 
9 

10 


Seismic  Data 
Host  Going  Down 
Operator  Message 
Status 

SIP  to  Datacomputer 
Transfer  Complete 

Processed  Data 
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Data  Type  0:  Seismic  Data 

4 ^ 

Seismic  Data  blocks  are  transmitted  from  the  CCP  to  the 
SIP  and  from  the  CCP  to  the  DP.  Each  block  contains  data  from  one 
station.  Data  blocks  will  be  time  ordered.  Data  format  of  the 
Seismic  Data  is  as  follows: 

Field  1:  Bytes  1 to  8:  Tlme-of-day 

16  BCD  characters  as  follows: 


/ n 
. n 


char. 

1 

2&3 

7,8 

9,10 

11,12 

13,1^ 

15,16 


two  digits  of  the  year 

three  digits  of  day  number 

two  digits  of  hours 

two  digits  of  minutes 

two  digits  of  seconds 

two  zeros  for  hundredths  of  seconds 

padding-zeros 


Field  2:  Bytes  9 to  11:  Site  identity 

3 ASCII  characters  of  site  name 


Field  3:  Byte  12:  Site  status 

MSB=1:  no  data  for  this  frame 

MSB-1=1:  communication  block  error  this  frame 


Field  4:  Seismic  data  Including 

Subfield  1:  SP  Status  padded  to  a word  boundary, 

Data  in  this  field  is  copied  from  the  incoming 
data  and,  therefore,  is  site  dependent.  See 
Appendix  B for  formats. 
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Subfield  2:  SP  data:  10  or  20  samples  (depending 

on  sample  rate)  for  each  SP  channel. 
Each  sample  is  a 16  bit  fixed  point 
number.  Samples  are  ordered  in  frames 
of  1/10  or  1/20  second  each  containing 
one  sample  from  each  seismometer. 

Subfield  3:  LP  status  padded  to  a word  boundary. 

See  Appendix  B for  format. 

Subfield  4:  LP  data:  1 sample  from  each  LP  seismo- 

meter. Each  sample  is  a 16  bit  gain 
ranged  number. 

Data  Type  4:  Host  Going  Down 

There  are  no  data  fields  in  a "Host  Going  Down"  block. 

Data  Type  6:  Operator  Messages 

The  data  consists  of  ASCII  text  bytes  representing  the 
operator  message.  The  data  field  is  padded  to  an  even  number 
of  bytes  (full  16  bit  word  boundary). 
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Data  Type  8:  Status  Data 

The  status  blocks  are  collected  Into  a file  in  the  archival 
storage.  This  file  is  used  as  1)  a record  of  the  state  of  the 
seismic  network  nodes,  and  2)  a record  of  data  available  from 
the  network.  The  CCP  maintains  a record  of  the  status  of  all 
sites  and  nodes  and  reports  changes  to  the  STP  and  to  the  DP. 

The  SIP  and  DP  will  maintain  a record  of  the  CCP  status  and 
will  make  entries  in  the  file  when  the  CCP  status  changes. 

The  data  format  for  status  blocks  is  as  follows: 

Field  1:  Bytes  1 to  6:  Time-of-day  coded  as  first 

six  bytes  of  time  in  the  Seismic  Data  block. 

Field  2:  Bytes  6 and  7:  Number  of  status  change 

entries  in  this  block. 

Field  3:  Status  change  entries 

Each  entry  consists  of  l4  bytes  coded  as 
follows : 

3 bytes  ASCII  characters  for  site  or  node  id. 

LA0  = LASA 
NA0  = NORSAR 
CCP  = CCP 
SIP  = SIP 
DPS  = DP 

000  = special  case,  complete  network  status 

will  be  reported  in  next  block. 

1 byte  ASCII  character  for  channel  type 

I = individual  sensor 
S = subarray  beam 
B = array  beam 
A = adaptive  beam 


9 


Report  No.  3460 


Bolt  Beranek  and  Newman  Inc. 


E = special  case,  status  applies  to  all  channels 
at  this  site.  This  byte  always  E for  SIP, 

CCP,  and  DPS.  This  byte  is  E for  sensor 
stations  when  the  smoothed  missing  message 
rate  or  checksum  error  rate  exceeds  threshold. 

2 bytes  ASCII  characters  for  sample  rate  in 
samples  per  second.  Zeros  if  channel  type  is 
E or  site  id  is  000. 

4 bytes  ASCII  characters  for  channel  id  within 
site.  Zeros  if  channel  type  is  E or  site  id  is 
000. 


1 byte  ASCII  character  for  gain 


H = high  gain 
L = low  gain 

0 = channel  type  is  E or  site  id  is  000 

1 byte  ASCII  character  for  sensor  component 

Z = vertical 
N = north 
E = east 
T = transverse 
R = radial 

0 = channel  type  is  E or  site  id  is  000 

1 byte  status  bits  coded  as  follows  (bit  1 is  MSB) 


bit  1=1 
bit  2=1 
bit  3=1 
bit  4=1 
bit  5=1 
bit  6=1 
bit  7=1 
bit  8=1 


no  data  or  node  down 
calibration  or  test 
communication  error 
data  suspect  or  bad 

CCP  operator  commanded  no  data  or  bad  data 
CCP  operator  commanded  calibration 
CCP  operator  commanded  communication  error 
CCP  operator  commanded  data  suspect 


1 byte  offset  location  of  sensor  in  site  data  starting 
at  0.  Zero  if  channel  type  is  E or  site  id  is  000. 
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Data  Type  9:  SIP  to  Datacomputer  Transfer  Complete 

Whenever  data  Is  transferred  from  the  SIP  disk  file  to  the 
Datacomputer,  a type  9 block  is  sent  to  the  CCP.  Format  of  the 
data  in  a type  9 block  is  as  follows: 

Field  1:  Bytes  1 to  4 : Three  bytes  of  site  id  and  one 

byte  padding. 

Field  2:  Bytes  5 to  1^:  Ten  ASCII  characters  file  name. 

Field  3:  Bytes  15  to  20:  Starting  time  of  the  filed  data 
using  the  same  coding  as  the  time-of-day  field 
in  the  status  block. 

Field  4:  Bytes  21  to  26:  Ending  time  of  the  filed  data 

using  the  same  coding  as  the  time-of-day  field 
in  the  status  block. 

Data  Type  10:  Processed  Data 

Processed  Data  blocks  are  exchanged  between  the  CCP  and  DP. 
They  contain  NORSAR  detection  and  event  data  sent  to  SDAC , and 
LASA  detection  data  to  be  sent  to  NORSAR.  Format  for  the  data 
in  the  processed  data  blocks  from  DP  to  CCP  is  as  follows : 

Field  1:  Bytes  1 to  6:  Time-of-day  coded  same  as  time- 

of-day  in  the  Status  block. 

Field  2:  Bytes  7 to  22  One  SDAC  Signal  Arrival  Queue 
entry  to  be  entered  into  field  1 of  the  next 
CCP  to  NORSAR  message. 
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16  byte  entry  coded  as  follows: 

bytes  1 to  ^ : Signal  start  time  In  declseconds 

bytes  5 to  8:  Signal  stop  time  in  declseconds 

bytes  9 and  10:  Detecting  beam  number 

bytes  11  and  12:  Maximum  short-time  average 

(MSTA)  level 

bytes  13  and  l4;  Long-time  average  (LTA) 
bytes  15  and  l6:  Detection  number  (a  counter 

that  is  incremented  by  one  in  successive 
messages  and  is  reset  when  the  SDAC  DPS 
system  is  initialized.) 

The  format  for  the  processed  data  in  the  processed  data 
blocks  from  the  CCP  to  the  DP  is  as  follows: 

Field  1:  Bytes  1 to  6:  Time-of-day  coded  same  as  time- 

of-day  in  the  Status  block. 

Field  2:  Bytes  7 to  24:  NORSAR  DP  results  from  field 

3 of  the  last  message  from  NORSAR.  Coding  is 
as  follows: 

4 bytes  - Start  time  (declsecond) 

4 bytes  - Stop  time  (declsecond) 

2 bytes(l6  bits)  - Beam  number 

(Bits  0-3)  - Number  of  subarrays  down 
(Bits  4015)  - Beam  number 
2 bytes  - MSTA 

2 bytes  - LTA 

2 bytes  - Detection  number 

The  detection  number  Increments  by  1 and  is 
reset  whenever  NORSAR  DP  is  initialized. 

2 bytes  - Partition  code 

Bits  0-4  of  last  byte  (filter  code)  is  X'F' 
for  general  surveillance  or  X'O'  for  selected 
surveillance.  Note  that  this  assumes  NORSAR 
will  continue  2-partltlon  DP  processing. 

When  no  detection  is  present,  this  field  is  encoded 
as  binary  zeros. 
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Field  3:  Bytes  25  to  80:  NORSAR  EP  results. 

56  bytes  from  the  NORSAR  EP  file  as  received  in 
field  8 of  the  last  message  from  NORSAR.  This 
field  consists  of  a ^-byte  Integer  transmission 
count  which  is  incremented  and  stored  with  each 
transmission  of  this  field;  a ^-byte  Integer  EPX 
number;  and  a 48-byte  area  containing  data  from 
the  NORSAR  automatic  EP  results  file.  If  no  EP 
results  are  present  this  field  is  coded  as  binary 
zeros . 

Acknowledge  Data  Format 

All  messages  between  the  CCP  and  SIP  and  between  the  CCP 
and  the  DP,  except  acknowledge  messages,  are  acknowledged  if 
they  have  correct  checksums.  Acknowledge  data  blocks  are  in 
separate  message  streams  with  one  acknowledge  block  in  each 
message.  Acknowledge  messages  will  not  exceed  one  ARPANET 
packet  (1008  bits). 

Acknowledge  messages  have  only  one  data  field  containing  a 
list  of  the  two  byte  message  identifier  counts  from  the  headers 
of  messages  being  acknowledged. 
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4.  HOST  LEVEL  BLOCK  AND  MESSAGE  HEADER  AND  CHECKSUMS 
4.1  Block  Header 

Each  of  the  data  blocks  described  in  section  3 above  except 
the  acknowledge  block  will  have  a four  byte  header  appended  when 
it  is  entered  into  its  appropriate  data  stream.  The  standard 
block  header  format  is  as  follows: 


Field  1:  Bytes  1 and  2:  Block  type.  A 16  bit  binary 

Integer  for  the  identifier  given  in  Table  1. 

Field  2:  Bytes  3 and  4:  Block  Length:  a l6  bit  binary 

integer  for  the  number  of  bytes  in  this  block 

(including  block  header). 

4.2  Message  Header  and  Checksums 

Each  of  the  two  data  streams  (one  for  all  block  types 
except  acknowledge  and  one  for  acknowledge  blocks)  will  be 
broken  into  messages  of  996  bytes  or  less  for  transmission  over 
the  ARPANET.  Each  message  will  have  an  8 byte  host  level  header 
appended  at  the  beginning  and  a 2 byte  checksum  added  at  the  end. 

The  format  of  the  header  will  be  as  follows: 


Byte  1:  Source  host  identification 

Byte  2:  Message  type 

1 » normal  data  stream  message 

2 ■ acknowledge  data  stream  message 
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Field  3:  Bytes  3 and  : Unique  message  Identifier  In 

the  form  of  a counter  for  messages  to  each 
receiving  host.  The  counter  provides  both  unique 
Identification  and  sequence  verification.  The 
counter  recycles  from  Its  maximum  logical  value 
of  FFFF  (hexadecimal)  to  the  value  1.  The  counter 
will  be  reset  to  0 whenever  the  sending  host  Is 
restarted  or  has  had  to  throw  data  away  due  to 
exceeding  Its  buffer  queue.  The  message  identifier 
In  acknowledge  messages  is  never  used,  and  Its 
value  is  optional  (sender's  choice). 

Field  Bytes  5 and  6:  Length  of  the  data  part  of  the 

message  (excluding  message  header  and  checksum 
but  Including  block  headers)  in  bytes. 

Field  5:  Bytes  7 and  8:  Length  of  the  tall  of  block  from 

previous  message  in  bytes  (acts  as  an  offset  to 
beginning  of  the  first  block  that  starts  in  this 
message).  Hexadecimal  FFFF  In  this  field  Indicates 
that  no  block  starts  In  this  message  (e.g.,  the 
entire  message  is  the  end  of  a block  that  started 
in  an  earlier  message).  0 indicates  that  the  data 
area  starts  with  a new  block.  This  field  is  always 
0 in  acknowledge  messages. 

The  checksum  field  will  be  a 16  bit  value  computed  by  sub- 
tracting the  arithmetic  sum  of  the  16  bit  value  of  the  words  in 
the  host  level  header  and  the  data  area  of  the  message  (exclude 
ARPANET  header  and  the  checksum  field)  from  the  number  of  16  bit 
words  included  using  binary  two's  complement  16  bit  arithmetic. 
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5.  ARPANET  HEADERS  AND  PROTOCOL 
5.1  Host-to-IMP  Header 

A Host-to-IMP  leader  must  be  appended  to  the  head  of  each 
message  to  be  transmitted  via  the  ARPANET.  There  are  now  two 
Versions  of  the  Host-to-IMP  leader  format.  The  new  version 
allows  addressing  more  than  4 hosts  on  an  IMP  and  more  than  64 
hosts  in  the  network.  The  change  is  backward  compatible,  so 
only  hosts  on  a fifth  host  port  or  an  IMP  numbered  greater  than 
64,  or  a host  communicating  with  another  host  in  that  category, 
are  required  to  use  the  new  leader.  The  CCP  and  DP  will  use  the 
new  leader.  Both  forms  of  leader  are  described  below. 


1 

] 

( 


a)  Old  leader  format 

The  old  Host-to-IMP  leader  consists  of  4 bytes  coded 
as  follows: 


bit  1:  Priority  bit=0  for  VELANET  messages, 

bits  2 to  8:  zeros. 

bits  9 and  10:  destination  host  number. 

bits  11  to  l6:  destination  IMP  number. 

bits  17  to  28:  message  id:  code  is  sending  host 

option. 


bits  24-32:  zeros. 


b)  New  leader  format 

The  new  Host-to-IMP  leader  consists  of  12  bytes 
(96  bits)  coded  as  follows: 


bits  1-4:  zeros, 

bits  5-8:  all  ones, 

bits  9-37:  zeros, 

bits  38-40:  ones 
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41-U8: 

destination 

bits 

: 

destination 

bits 

65-76: 

message  Id: 

bits 

77-96: 

zeros . 
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IMP. 

code  is  sending  host  option. 


Report  No.  3460 


Bolt  Beranek  and  Newman  Inc. 


6.  HOST  PROTOCOL  RULES 
6.1  Normal  Operation 

During  normal  operation  the  data  exchange  among  the  CCP, 

DP,  and  SIP  Include: 

a)  One  frame  of  seismic  data,  including  short  period  and 
long  period  data  from  each  operating  site,  is  available 
at  the  CCP  for  transmission  to  DP  and  SIP.  The  subset 
of  the  data  that  is  sent  to  each  receiver  is  determined 
by  parameters  in  the  CCP.  The  CCP  operator  may  be  able 
to  change  these  parameters  by  operator  command,  but  the 
VELANET  protocols  do  not  include  provision  for  dynamic 
changes.  Initial  data  will  be  transmitted  from  the  CCP 
in  chronologic  order.  Retransmissions  of  lost  or  bad 
messages  may  occur  at  any  time. 

b)  Each  second  the  CCP  may  have  processed  data  to  send  to 
DP  if  NORSAR  is  operating.  Each  second  the  DP  may  have 
processed  data  to  send  to  the  CCP,  but  more  likely 
every  2 minutes. 

c)  Operator  messages  may  be  generated  at  the  SIP  or  the 
CCP  at  any  time. 

d)  The  CCP  will  monitor  status  of  all  other  nodes  and  sites 
on  the  VELANET  and  will  monitor  status  of  all  sensors. 
Whenever  a change  in  status  of  sensors  being  sent  to 

DP  or  SIP  occurs,  status  change  data  will  be  sent  from 
the  CCP  to  DP  and/or  SIP.  Whenever  a change  in  SIP  or 
DP  status  occurs,  CCP  will  send  a status  change  report 
to  SIP  and  DP.  Thus  all  status  data  will  appear  in 
both  SIP  and  DP  archival  files  except  for  complete  net- 
work status  entries  on  restart  of  SIP  or  DP. 
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SIP  and  DP  will  monitor  CCP  status  and  will  generate 
a status  block  for  CCP  when  the  CCP  status  changes. 

At  midnight  GMT,  CCP  will  send  the  full  status  of 
the  entire  VELANET  to  SIP  and  DP. 

e)  Whenever  the  SIP  completes  a transfer  of  data  from  the 
SIP  disc  file  to  the  Datacomputer , the  SIP  will  generate 
a data  filed  report  for  the  CCP. 

All  of  the  above  reports  will  be  entered  as  data  blocks  in 
the  main  data  stream  buffers.  Whenever  there  is  enough  data  for 
any  connection  to  generate  a full  ARPANET  message  or  the  oldest 
waiting  data  block  is  one  second  old,  the  data  will  be  assembled 
into  an  ARPANET  message  and  transmitted  unless  the  connection 
would  be  blocked  (see  abnormal  operation  below). 

Whenever  a message  from  the  main  data  stream  is  received 
with  the  correct  checksum,  an  acknowledge  report  for  taat  message 
is  generated.  Acknowledge  data  form  a separate  data  stream. 
Acknowledge  messages  are  transmitted  at  least  once  each  second 
if  any  acknowledge  data  are  present.  Acknowledge  messages  are 
not  acknowledged. 

After  transmission  of  a main  data  stream  message,  the 
sending  node  saves  a copy  of  the  message  until  it  is  acknowledged 
or  alloted  buffer  space  is  filled.  Messages  will  be  retransmitted 
every  five  seconds  until  they  are  acknowledged  or  until  the  buffer 
must  be  reused.  Five  seconds  is  an  initial  value  that  may  be 
changed  on  operational  experience. 

Since  the  CCP  and  possibly  the  DP  may  be  on  eitiior  of  two 
host  connections  to  the  network,  the  correct  host  address  will 
be  determined  as  follows: 
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a)  The  DP  and  SIP  will  send  messages  to  the  host  address 
from  which  they  received  the  most  recent  valid  data 
message . 

b)  The  CCP  will  send  messages  to  the  host  address  entered 
by  the  CCP  operator. 
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6.2  Abnormal  Operations  and  Restart 

The  CCP,  SIP,  and  DP  must  recognize  and  respond  to  several 
abnormal  conditions.  The  symptoms  and  response  to  these  condi- 
tions are  summarized  below.  The  more  complex  response  sequences 
are  described  in  more  detail  in  Appendix  A. 

6.2.1  Communications  and  Control  Processor  (CCP) 

a)  DP  or  SIP  communications  about-to-block . 

Symptom : 

1.  The  CCP  will  keep  a separate  account  of  the  oldest  ARPANET 
messages  in  flight  to  DP  and  SIP.  When  5 more  recent  mes- 
sages have  been  transmitted,  that  communication  stream  is 
about  to  block.  (Before  the  Pluribus  IMP  is  installed  at 
CCA,  the  SIP  data  stream  will  be  about  to  block  if  2 more 
recent  messages  have  been  sent . ) 

Response : 

1.  The  CCP  will  not  transmit  any  additional  messages  to  the 
host  that  is  about  to  block  until  a RFNM  or  lost  message 
is  received  for  the  oldest  outstanding  message  in  that 
data  stream. 

2.  The  CCP  will  print  an  operator  message 

(time)  SIP  (DP)  about-to-block 
when  the  condition  occurs  and  a message 
(time)  SIP  (DP)  unblocked 
when  transmission  is  resumed. 

b)  DP  or  SIP  down  or  inaccessible. 

Symptom : 

1.  Type  7 IMP-to-Host  message  received. 
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Response  : 

1.  The  CCP  will  attempt  to  transmit  the  rejected 
message  every  1 to  2 seconds  to  test  for  return  to 
normal  operation.  No  other  messages  will  be  sent 
to  the  inaccessible  host  until  the  communication 
path  is  reestablished. 

2.  CCP  will  print  an  operator  message 

(time)  SIP  (DP)  down  (type) 

(type  = numerical  value  of  the  subtype  of  the  IMP- 
to-Host  message) 

when  the  condition  is  detected,  and  a message 
(time)  SIP  (DP)  up 
when  the  condition  ends. 

c)  Data  loss  on  the  DP  or  SIP  communication  stream. 
Symptom : 

Buffer  space  available  for  the  data  stream  is  exceeded. 
This  condition  occurs  if  data  can  not  be  transmitted  as 
fast  as  it  is  received,  usually  because  the  destination 
host  (DP  or  SIP)  is  blocked  or  down. 

Response : 

1.  Clear  all  data  being  buffered  for  that  particular 
(DP  or  SIP)  data  stream  and  stop  making  new  data 
blocks  for  that  stream. 

2.  Restart  the  offending  data  stream  (DP  or  SIP).* 


' *See  Appendix  A 
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3.  Print  an  operator  message  tagged  with  the  time  of  the 
oldest  data  lost 

(time)  SIP  (DP)  data  lost 
and,  when  communication  is  restored, 

(time)  SIP  (DP)  data  restored 

4.  Send  status  change  messages  to  the  other  archiving  host 

(DP  or  SIP)  giving  time  "no  data"  condition  starts  and  ends. 

d)  Host-to-IMP  error  or  SDAC  IMP  down. 

Symptoms : 

1.  IMP  ready  line  down. 

2.  Type  1 or  Type  8 IMP-to-Host  message. 

Response : 

1.  Reset  IMP  data  stream.* 

2.  Print  a CCP  operator  message 

(time)  Host-IMP  Error 

and,  when  successful  communications  are  resumed,  print 
an  operator  message 

(time)  Host-IMP  good. 

e)  DP  or  SIP  saw  CCP  down. 

Symptom; 

1.  Received  a CCP  down  status  change  block  from  DP  or  SIP. 
Response : 

1.  Print  operator  messages 
(time)  CCP  down 


•See  Appendix  A 
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(time)  CCP  up  j 

2.  Send  status  change  blocks  to  the  other  (SIP  or  DP)  archiving 

host  showing  CCP  "no  data"  start  and  end  times.  j 

f)  Incoming  data  stream  reset.  j 

Symptom : 

1.  Received  message  with  ld=0  from  SIP  or  DP.  j 

Response ; 

1.  Clear  any  partial  data  blocks  from  the  source  that  { 

sent  the  id=0  message  (DP  or  SIP). 

2.  Type  operator  message  I 

(time)  SIP  (DP)  reset  | 

g)  CCP  Restart. 

Symptom:  | 

1.  Operator  or  reliability  code  restart  of  CCP. 

Response : I 

1.  Clear  buffers.  i 

2.  Reset  IMP  data  stream.* 

3.  Reset  output  data  streams  to  SIP  and  DP.*  | 

4.  Print  operator  message 

(time)  CCP  Restart 

5.  If  first  message  from  DP  or  SIP  contains  a CCP  down 
status  change,  send  CCP  down  (and  up)  status  change 
messages  to  archival  stores  (SIP  and  DP). 


*See  Appendix  A 
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6.2.2  Detection  Processor  (DP) 

The  DP  must  recognize  and  respond  to  at  least  the  following 
abnormal  conditions: 

a)  Incoming  data  stream  from  CCP  reset. 

Symptom : 

1.  Received  a message  from  CCP  with  ld=0. 

Response : 

1.  Delete  any  partial  incoming  data  blocks  being  saved 
pending  completion. 

2.  Reset  incoming  message  id  reference. 

b)  Host-to-IMP  error  or  SDAC  IMP  down. 

Symptom: 

1.  IMP  ready  line  down. 

2.  Type  1 or  type  8 IMP-to-Host  message. 

Response : 

1.  Reset  the  IMP  data  stream.* 

c)  CCP  down  or  inaccessible. 

Symptom: 

1.  IMP-to-Host  type  7 message. 


•See  Appendix  A 
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Response : 

1.  Test  for  CCP  up  by  attempting  to  send  a CCP  down 
status  change  message  periodically  until  it  Is 
successful . 

2.  Enter  CCP  down  ("no  data")  status  change  In  archival 
storage . 

3.  Send  a CCP  up  status  change  and  resume  normal 
operation . 

4.  Enter  CCP  up  ("no  data"  bit  off)  status  change  in 
archival  storage. 

d)  DP  restart. 

Symptom: 

1.  Operator  restart  DP  system. 

Response : 

1.  Reset  IMP  data  stream.* 

2.  Reset  CCP  data  stream.* 

e)  DP  out  of  buffers  for  CCP  messages. 

Symptom: 

1.  Buffer  space  for  messages  to  CCP  full.  (Probable 

causes  are  blocking  of  Host-to-IMP  data  or  CCP  down.) 


•See  Appendix  A 
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Response : 

Since  all  messages  from  DP  to  CCP  are  the  result 
of  operations  internal  to  DP,  not  forwarding  continuous 
data  from  Input  data  streams,  the  DP  has  two  choices: 

1)  DP  can  stop  making  up  output  messages 
for  CCP  until  buffers  are  available, 

or 

1)  DP  can  clear  all  data  being  buffered 
rt>r  CCP  except  CCP  down  status  and  stop 
making  up  new  output  messages. 

2)  Restart  CCP  data  stream*  when  buffers 
available . 

6.2.3  Seismic  Input  Processor  (SIP) 

The  SIP  must  recognize  and  respond  to  the  same  conditions 
as  the  DP  with  corresponding  responses. 


•See  Appendix  A 
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APPENDIX  A 

The  procedures  for  resetting  the  Host-to-IMP  data  stream 
and  the  Host-to-Host  data  stream  are  described  below. 

Reset  the  IMP  data  stream:  In  order  to  reset  the  IMP 

data  stream,  the  host  will: 

1.  Set  the  host  ready  line  up  and  monitor  the  IMP 
ready  line  until  It  Is  up. 

2.  Transmit  3 Host-to-IMP  type  ^ NOP  messages  to  the 
IMP. 

3.  Retransmit  the  Host-to-Host  message  that  caused  the 
IMP-to-Host  error  message,  if  any. 

4.  Resume  normal  operation. 

Reset  the  Host  data  stream:  in  order  to  reset  the  data 

stream  to  an  Individual  host  (CCP,  SIP  or  DP),  the 

sending  host  will : 

1.  Reset  the  message  id  counter  for  that  data  stream  to  0. 

2.  Prepare  and  attempt  to  send  a message  to  the  receiving 
host  with  ld=0  and  the  following  data  blocks: 

a)  If  the  CCP  Is  the  sending  host,  and  the  time  of 
data  that  was  lost  is  known  from  the  time  of 
the  oldest  buffer  that  was  cleared  or  from  an 
Incoming  CCP  down  status  change  message,  the 
first  data  block  will  be  a status  change  block 
showing  "no  data"  for  the  receiving  host  (SIP 
or  DP)  at  that  time. 
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b)  If  the  CCP  Is  the  sending  host,  a status 
change  block  for  the  entire  VELANET  for  the 
time  of  restart  will  be  Included.  This 
status  change  will  show  the  receiving  host 
(SIP  or  DP)  up  ("no  data"  bit  off). 

c)  The  first  normal  block  to  be  sent  after  the 
reset . 

3.  Wait  for  the  acknowledge  for  the  above  message  with 
ld=(2f. 

4.  Resume  normal  operation. 
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APPENDIX  B:  Data  Status  Field  Formats 

Only  LASA  and  NORSAR  stations  include  status  fields  in  the 
data  messages.  The  format  of  these  fields  is  described  below: 


1 . LASA 

a)  Short  Period  Data  Status 


Subfield  Length 

(Bits)  Subfield  Use 


156  Per  each  of  13  beams,  there  are 

12  bits . 

Bit  0:  1 = not  present 

Bit  1:  1 = calibration 

Bits  2-11:  1 = bad  more  than 

X%  of  time 

4 Zeros 

18  Per  each  of  6 raw  sensors,  there 

are  three  bits. 

Bit  0:  1 * not  present 

Bit  1:  1 = calibration 

Bit  2:  1 = bad/operator  encoded 

14  Zeros 

60  One  bit  for  each  of  6 raw  channels 

repeated  every  1/10  sec. 

Bit  value;  1 = bad  (parity/ 
glitch  detected) 

4 Zeros 

256  Total  SP  Status  Field  Length 
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b)  Long  Period  Data  Status 


Subfield  Length 
(Bits) 

Subfield 

Use 

120 

There 

are 

four  bits  per  each  of 

the  30 

LP 

channels . 

Bit 

0 ; 

1 = absent 

Bit 

1: 

1 = calibration 

Bit 

2: 

1 = data  bad 

Bit 

3: 

1 = operator  declared 

channel  bad 

8 

Zeros 

128 

Total 

LP 

Status  Field  Length 

NORSAR 

a)  Short  Period  Data 

Status 

Subfield  Length 

(Bits) Subfield  Use 


48  There  are  16  bits  per  each  of  3 

SP  channels 

Bits  0-3:  type  of  channel  ID 

4-15:  channel  or  beam  number 
of  data 

1 SP  repeat  indicator 

15  Zeros 

64  Total  SP  Status  Field  Length 

b)  Long  Period  Data  Status 


Subfield  Length 

(Bits) Sub  field  Use 


66  One  bit  for  each  LP  sensor:  i.e., 

3 blts/subarray  with  order  LV,  LN, 
LE.  If  status  bit  * 1,  error. 

12  Zeros 

1 Undefined 

1 LP  repeat  Indicator 


80  Total  LP  Stc^’us  Field  Length 
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NOTE:  NORSAR  Long  Period  Status  Field  will  be  changed 

to  the  following  format,  probably  In  April  of  1977. 

Sub fie Id  Length 

(Bltt  Subfield  Use 


21  One  bit  for  each  high  gain  LP 

sensor,  3 blts/subarray  In  order 
LV,  LN,  LE. 

3 One  bit  for  each  low  gain  LP 

sensor. 

13  Zeros 

3 Low  gain  subarray  Identity 

7 Zeros 

1 LP  repeat  indicator 

48 


Total  LP  Status  Field  Length 
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